
An HTTP 500 Internal Server Error means the server encountered a condition that prevented it from completing the request, but the response does not identify the cause. The problem may be in application code, a PHP runtime, server configuration, permissions, resource limits, or an upstream service.
Check whether the error affects every page, one URL, the administration area, or only a specific action. Test from another browser or network if practical, and note the exact time. A site-wide failure suggests a different investigation path from a single broken plugin page.
| Observed behavior | Possible direction |
|---|---|
| Every URL returns 500 | Server configuration, runtime, broad application failure |
| Only one route fails | Specific code path, rewrite rule, plugin, or data |
| Failure began after an update | Compatibility or deployment regression |
| Intermittent failures | Resource limits, upstream dependency, or load |
The most useful evidence is often in the web server error log, PHP error log, or application log. Look for entries matching the time of the failed request. Common clues include fatal errors, uncaught exceptions, missing files, permission denied messages, memory exhaustion, and syntax errors.
Log locations vary by server and hosting configuration. A control panel may expose logs in its interface, while a VPS administrator may inspect service-specific log files with tools such as journalctl. Do not assume one path applies to every host.
Ask what changed immediately before the error appeared: a plugin update, theme edit, PHP version switch, .htaccess modification, deployment, permissions change, or database migration. If the timing lines up, test that change first rather than changing several unrelated settings.
When possible, reproduce the issue in staging. If a rollback is necessary, revert the smallest known change and verify the site. Keep a record of what was reverted so the underlying cause can still be fixed.
On PHP sites, a fatal error can produce a 500 response. Common causes include calling an undefined function, incompatible plugin code, missing extensions, syntax errors, and exhausted memory. Compare the active PHP version and enabled extensions with the application’s requirements.
Do not enable public error display as a permanent debugging method. Detailed traces may reveal filesystem paths or sensitive implementation details. Prefer protected logs and disable verbose debugging when the investigation is complete.
A malformed rewrite or server configuration can prevent requests from being handled. On Apache, a problematic .htaccess directive may cause a 500 response, particularly when the directive is not permitted by the server configuration. A permissions change can also prevent the server from reading files or traversing directories.
Do not delete configuration files blindly. Make a copy, change one thing at a time, and preserve the original so it can be restored.
Memory limits, process limits, execution timeouts, database connection failures, and unavailable external APIs can all contribute to failed requests. If the error is intermittent, correlate timestamps with resource usage and service logs. A 500 response alone does not prove that the server is underpowered.
Provide the affected URL, timestamp with time zone, error text, and steps to reproduce. Include relevant log excerpts, but remove passwords, tokens, and personal information. If the error is limited to a server-level service or account restriction you cannot inspect, the provider may need to investigate.
A 500 error is intentionally generic, so reliable troubleshooting depends on narrowing the scope and finding the corresponding log entry. Avoid making multiple speculative changes. A methodical investigation is faster and less likely to create a second problem.